=== WP Staging Pro - DB & File Duplicator & Migration  === 

Author URL: https://wordpress.org/plugins/wp-staging
Plugin URL: https://wordpress.org/plugins/wp-staging
Contributors: ReneHermi, WP-Staging
Donate link: https://wordpress.org/plugins/wp-staging
License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Tags: staging, duplication, cloning, clone, migration, sandbox, test site, testing, backup, post, admin, administration, duplicate posts
Requires at least: 3.6+
Tested up to: 5.2
Stable tag: 2.9.0 
Requires PHP: 5.3

A duplicator plugin! Clone, duplicate and migrate live sites to independent staging and development sites that are available only to administrators.

== Description == 

<strong>This cloning and staging plugin is well tested but still work in progress! <br>
If you find a bug please open a ticket in the [support request](https://wordpress.org/support/plugin/wp-staging/ "support forum"). Any issues will be fixed asap!
</strong>
<br /><br />
<strong>Note: </strong> This plugin is not able to push back your changes to the live site at the moment! 
Please let us know your most requested feature and use our quick poll. It only takes one minute of your time: [Start the poll](https://docs.google.com/forms/d/e/1FAIpQLScZ-dO5WffV3xObn16LwG05tr1HrADD_8L4wbTxPHqoPssVcg/viewform?c=0&w=1&usp=mail_form_link "wp staging poll")
<br /> <br />


<blockquote>
<h4> WP Staging for WordPress Migration </h4>
This duplicator plugin allows you to create an staging or development environment in seconds* <br /> <br />
It creates a file clone of your website into a subfolder of your current WordPress installation with an entire copy of your database. 
This sounds pretty simple and yes it is! All the hard time consumptive database and file copy stuff including url replacements is done in the background.
 <br /> <br />
I created this plugin because all other solutions are way too complex, overloaded with dozens of options or having server requirements which are not available on most shared hosting solutions.
All these reasons prevent user from testing new plugins and updates first before installing them on their live website, so its time to release a plugin which has the potential to be merged into everyone´s wordpress workflow.
 <br /> <br />
<p><small><em>* Time of creation depends on size of your database and file size</em></small></p>
</blockquote>

WP Staging helps you to prevent your website from being broken or unavailable because of installing untested plugin updates! 

[youtube https://www.youtube.com/watch?v=Ye3fC6cdB3A]

= Main Features =

* <strong>Easy: </strong> Staging migration applicable for everyone. No configuration needed!
* <strong>Fast: </strong> Migration process lasts only a few seconds or minutes, depending on the site's size and server I/O power
* <strong>Safe: </strong> Access to staging site is granted for administrators only.
<br /><br />
<strong>More safe:</strong> 
<br>
* Admin bar reflects that you are working on a staging site
* Extensive logging if duplication or  migration process should fail.
* New: Compatible to All In One WP Security & Firewall

= What does not work or is not tested when running wordpress migration? =

* Wordpress migration of wordpress multisites (not tested)
* WordPress duplicating process on windows server (not tested but will probably work) 
Edit: Duplication on windows server seems to be working well: [Read more](https://wordpress.org/support/topic/wont-copy-files?replies=5 "Read more") 


<strong>Change your workflow of updating themes and plugins data:</strong>

1. Use WP Staging for migration of a production website to a clone site for staging purposes
2. Customize theme, configuration and plugins or install new plugins
3. Test everything on your staging site first
4. Everything running as expected? You are on the save side for migration of all these modifications to your production site!


<h3> Why should i use a staging website? </h3>

Plugin updates and theme customizations should be tested on a staging platform first. Its recommended to have the staging platform on the same server where the production website is located.
When you run a plugin update or plan to install a new one, it is a necessary task to check first the modifications on a clone of your production website.
This makes sure that any modifications is  working on your website without throwing unexpected errors or preventing your site from loading. (Better known as the wordpress blank page error)

Testing a plugin update before installing it in live environment isn´t done very often by most user because existing staging solutions are too complex and need a lot of time to create a 
up-to-date copy of your website.

Some people are also afraid of installing plugins updates because they follow the rule "never touch a running system" with having in mind that untested updates are increasing the risk of breaking their site.
I totally understand this and i am guilty as well here, but unfortunately this leads to one of the main reasons why WordPress installations are often outdated, not updated at all and unsecure due to this non-update behavior.

<strong> I think its time to change this, so i created "WP Staging" for WordPress migration of staging sites</strong>

<h3> Can´t i just use my local wordpress development copy for testing like xampp / lampp? </h3>

Nope! If your local hardware and software environment is not a 100% exact clone of your production server there is NO guarantee that every aspect 
of your local copy is working on your live website exactely as you would expect it. 
There are some obvious things like differences in the config of php and the server you are running but even such non obvious settings like the amount of ram or the 
the cpu performance can lead to unexpected results on your production website. 
There are dozens of other possible cause of failure which can not be handled well when you are testing your changes on a local staging platform.

This is were WP Staging steps in... Site cloning and staging site creation simplified!

<h3>I just want to migrate the database from one installation to another</h3>
If you want to migrate your local database to a already existing production site you can use a tool like WP Migrate DB.
WP Staging is only for creating a staging site with latest data from your production site. So it goes the opposite way of WP Migrate DB.
Both tools are excellent cooperating eachother.

<h3>What are the benefits compared to a plugin like Duplicator?</h3>
At first, i love the [Duplicator plugin](https://wordpress.org/plugins/duplicator/ "Duplicator plugin"). Duplicator is a great tool for migrating from development site to production one or from production site to development one. 
The downside is that Duplicator needs adjustments, manually interventions and prerequirements for this. Duplicator also needs some skills to be able to create a development / staging site, where WP Staging does not need more than a click from you.
However, Duplicator is best placed to be a tool for first-time creation of your production site. This is something where it is very handy and powerful.

So, if you have created a local or webhosted development site and you need to migrate this site the first time to your production domain than you are doing nothing wrong with using
the Duplicator plugin! If you need all you latest production data like posts, updated plugins, theme data and styles in a testing environment than i recommend to use WP Staging instead!

= I need you feedback =
This plugin has been done in hundreds of hours to work on even the smallest shared webhosting package but i am limited in testing this only on a handful of different server so i need your help:
Please open a [support request](https://wordpress.org/support/plugin/wp-staging/ "support request") and describe your problem exactely. In wp-content/wp-staging/logs you find extended logfiles. Have a look at them and let me know the error-thrown lines.


= Important =

Permalinks are disabled on the staging site because the staging site is cloned into a subfolder and permalinks are not working on all systems
without doing changes to the .htaccess (Apache server) or nginx.conf (Nginx Server). 
[Read here](https://wp-staging.com/docs/activate-permalinks-staging-site/ "activate permalinks on staging site") how to activate permalinks on the staging site.

 
= How to install and setup? =
Install it via the admin dashboard and to 'Plugins', click 'Add New' and search the plugins for 'Staging'. Install the plugin with 'Install Now'.
After installation goto the settings page 'Staging' and do your adjustments there.


== Frequently Asked Questions ==

* I can not login to the staging site
If you are using a security plugin like All In One WP Security & Firewall you need to install latest version of WP Staging. 
Go to WP Staging > Settings and add the slug to the custom login page which you set up in All In One WP Security & Firewall plugin.



== Official Site ==
https://wp-staging.com

== Installation ==
1. Download the file "wp-staging-pro.zip":
2. Upload and install it via the WordPress plugin backend wp-admin > plugins > add new > uploads
3. Activate the plugin through the 'Plugins' menu in WordPress.
4. Start Plugins->Staging

== Screenshots ==

1. Step 1. Create new WordPress staging site
2. Step 2. Scanning your website for files and database tables
3. Step 3. Wordpress Staging site creation in progress
4. Finish!

== Changelog ==

= 2.9.0 =
* New: Improve styling of login form. Thanks to Andy Kennan (Screaming Frog)
* New: Add 'password lost' button to login form
* New: Improve styling of select all tables button
* New: Add new filter wpstg_cloning_target_dir
* New: Add new filter wpstg_cloning_target_hostname
* New: Add arguments for hook wpstg_cloning_complete
* New: Setup server environment variables per process and not globally (e.g. set_time_limit)
* Fix: Pushing a main multisite from an external database can result in preselected tables of child sites.
* Fix: Improve wordings
* Fix: Staging site could not be deleted even though the staging site folder is completely empty.
* Fix: Do not copy WP Staging Hooks plugin from staging to live to make sure to not overwrite its custom data
* Fix: Make sure WP Staging Hooks plugin keeps activated on the production site after pushing (If it exists and is active)
* Fix: PDO instances can not be serialized or unserialized
* Fix: New tables that do not already exist on the live site will not transfered from staging site to production site
* Fix: Add UPLOAD constant to wp-config.php of staging site does not work under all circumstances for cloning multisites
* Fix: Can not update staging site db table if there are constraints in it
* Fix: If custom destination dir is used it does not check if there are already files in the selected folder before cloning
* Fix: Improve deleting process
* Fix: Do not show error "Preparing Data Step3: Failed to update rewrite_rules in wpstg0_options"
* Fix: Change error "Table wpstgtmp_options does not exist" to warning

= 2.8.9 =
* Fix: Remove search & replace maximum value detection for cloning wp multisites

= 2.8.8 =
* Fix: Add filter wpstg_folder_permission to set a custom folder permission like 0755, allows to overwrite FS_CHMOD_DIR if it has been defined.
* Fix: Cloned multisite can not connect due to missing db credentials in wp-config.php
* New: Compatible up to WordPress 5.2.2

= 2.8.7 =
* Fix: Excluded folders under wp-content level are not take into account on microsoft IIS servers 
* Fix: Error conditions in class Data does not compare type strict (== vs. ==)  resulting in interruption of clone process
* Fix: Cloning a multisite to an external database results in broken images due to wrong upload path
* Fix: Disable foreign key check to prevent interuption of database duplication when foreign keys are used and db is cloned to external database
* Fix: Add filter wpstg_folder_permission to set a custom folder permission like 0755, allows to overwrite FS_CHMOD_DIR if it has been defined.
* New: Performance improvement for directory iterator using less server ressources
* New: Compatible up to WordPress 5.2.2

= 2.8.6 =
* Fix: Throw fatal error if selected target directory is the same as production website
* Fix: Can not copy database tables if mysql version on live and staging site is different and if one version is below mysql 5.6
* Fix: Make sure no whitespace characters are contained in beginning and end of the string target directory due to copy & paste issues
* Fix: Cloning a multisite to another database does not work as wp_users and wp_usermeta is not copied
* Tweak: Improve FAQ

= 2.8.5 =
* New: Update for WP 5.2.1
* New: Better warning notices before updating process is executed
* New: Better corporate identity and more friendly UI colors for staging sites listings and button
* New: Add tooltips for explaining navigation buttons
* Fix: Custom Database prefix is not stored and leads to empty table selection when trying to push
* Fix: Do not search & replace through "__PHP_Incomplete_Class_Name" definitions
* Fix: Cloning to external database does not go to the end under certain circumstances
* Fix: Prevent wordfence firewall rule interrupting the clone deletion method
* Fix: Copy web.config when site is cloned to a custom destination directory and subdomain
* Fix: Remove whitespace from target hostname
* Fix: Can not detect and push staging site created with older version of wp staging and which contains capitalized clone name
* Fix: Can not push staging site that has whitespaces in its name
* Fix: Strip whitespaces in cloning site internal names


= 2.8.4 =
* New: Compatible to WordPress 5.2
* New: Allow adding file .wp-staging to root of website to determine if it's a staging or production website
* New: Show unfinished or interrupted clones and allow deletion of them
* Fix: Convert staging site table prefix to lowercase
* Fix: Links in certain db rows are not changed with search & replace method if in the same db row is a mail address available.


= 2.8.3 =
* Fix: WordFence firewall rule 'local file inclusion' blocks wp staging initial starting cloning sequence
* Fix: Values of form Extra directories to copy are ignored
* Fix: Excluding tables or folders at the delete process are ignored
* Fix: Multisite cloning misses the tables _users and _usermeta. No login possible
* New: Add filter wpstg_push_excluded_files to exclude certain files from pushing

= 2.8.2 =
* Fix: Check if posix_getpwuid exists before using it in system info log
* Fix: Undefined offset
* Fix: Improve compatibility for the care case where wp upload folder is the same as wp-content
* Security: Remove storing of old db paassword
* New: Do not change the upload folder structure for using multisites
* New: Add hooks that can be used to trigger external actions after cloning and pushing, see https://github.com/rene-hermenau/wp-staging-hooks

= 2.8.1 =
* Fix: Lower the memory consumption when cloning scan process is started
* Fix: wp-content subfolders are excluded when cloning is started

= 2.8.0 =
* Tweak: Better database connection check
* Tweak: remove error message when siteurl and home url can not be replaced when it has been done already
* Fix: Lower the memory consumption when cloning scan process is started
* Fix: Disable the WP-Spamshield Plugin on staging site because it prevents login to staging site
* Fix: Does not copy .htaccess when site is cloned to external subdomain. Throwing warning notices.

 
= 2.7.9 =
* Fix: Update cron method throws fatal error

= 2.7.8 =
* New: Show update notifications in WP Staging User Interface
* New: Save folder and database table selection of the last push
* Fix: Cron job for checking plugin does not work properly

= 2.7.7 =
* New: Open system info log file directly via wp staging > tools
* New: Setting to preserve the permalink setting of the production site
* New: Tested for WordPress 5.1.1

* Fix: Search & Replace is not executed when staging site is located in separate database
* Fix: Prevent error message "can not find wpstgtmp_options" in data crunching step 10
* Fix: If multisite is installed in subdirectory, search & replace is not returning the correct siteurl and home
* Fix: Select All button for db tables not working in push menu
* Fix: If website is cloned to a custom directory let's copy the .htaccess as it is assumed that the staging site is copied to a subdomain
* Fix: Create "Set Default" link to be able to take over the default target hostname and target directory in advanced settings
* Fix: Theme folder is excluded from pushing when its name is the same as the name of the staging site
* Clean Up: Move admin notices to new location /views/includes/notices


= 2.7.6 =
* New: Add Filter to exclude certain tables from search & replace operation
* New: Check if there is already one process running before executing the cloning process
* New: Change WPSTGPRO_PLUGIN_DIR to WPSTG_PLUGIN_DIR
* New: Show PHP user in system info
* New: Support up to WordPress 5.1


= 2.7.5 =
* New: Add new db table selection manager
* New: Allow selection of db tables which has no WP prefix
* Tweak: DB tables and file verification opened as default option
* Tweak: clean up search & replace method
* Fix: Continue cloning if siteurl & home in wp_options could not be changed

= 2.7.4 =
* Fix: wp-config is not copied to the staging site when site is cloned to external database and on multisites
* Fix: Log file folder does not have correct permission 0755
* Tweak: Better warning for update method
* Tweak: Add notice to save permalink settings after pushing
* New: Support search & replace over single or double stroke constants definitions in wp-config.php
* New: New faq entry (page not found error 404)
* New: Bedrock compatibility. Create default wp-config.php if original wp-config is not in the default path


= 2.7.3 =
* Fix: Make sure that active user is not logged out while pushing the staging site
* Fix: Stop delete process if staging site has been deleted manually before
* Fix: Plugin not translated properly

= 2.7.2 =
* Fix: If backslash is contained in password of external database then the pushing fails
* Fix: Improve search & replace parameter for url's
* New: Explain the target directory
* New: Remove folder Library and move class Browser to Utils

= 2.7.1 =
* New: Better word of possible consequences before pushing for woocommerce owners
* New: Add FAQ to footer

= 2.7.0 =
* New: Tested up to WordPress 5.0.3 Gutenberg
* New: Skip table columns with more than 5MB for search & replace operations to inmprove performance

= 2.6.9 =
* Fix: WP Staging does not run with old WordPress version 3.2

= 2.6.8 =
* New: Tested up to WordPress 5.0.2 Gutenberg
* Fix: Error no such file in systeminfo 
* Fix: Prevent throwing error when table prefix of table usermeta can not be changed
* Fix: If backslash is contained in password of external database then the processing fails
* Fix: Pushing interrupts if password of current user is different on staging and live site

= 2.6.7 =
* Fix: Can not login to staging site . Changed minimum user capability to 'manage_options' instead 'administrator' ´

= 2.6.6 =
* New: Tested up to WordPress 5.0 Gutenberg
* New: Tested up to WordPress 5.0.1 Gutenberg
* New: Check if WordPress version number of staging and production site is identical before pushing
* New: Show WP version of staging site in the sysinfo log
* Fix: Make sure optimizer must-use plugin is updated as well after updating the main plugin
* Fix: When custom upload_path is used upload path is broken after pushing
* Fix: Security, prevent downloading wp staging log files by third party users from uploads folder
* Fix: Prevent error $this not in object context in install.php


Complete changelog: [https://wp-staging.com/changelog.txt](https://wp-staging.com/changelog.txt)

== Upgrade Notice ==

= 2.8.5 =
* New: Better warning notices before updating process is executed
* New: Better corporate identity and more friendly UI colors for staging sites listings and button
* New: Add tooltips for explaining navigation buttons
* Fix: Custom Database prefix is not stored and leads to empty table selection when trying to push
* Fix: Do not search & replace through "__PHP_Incomplete_Class_Name" definitions
* Fix: Cloning to external database does not go to the end under certain circumstances
* Fix: Prevent wordfence firewall rule interrupting the clone deletion method
* Fix: Copy web.config when site is cloned to a custom destination directory and subdomain
* Fix: Remove whitespace from target hostname
* Fix: Can not detect and push staging site created with older version of wp staging and which contains capitalized clone name
* Fix: Can not push staging site that has whitespaces in its name
