Export Profiles
-
Hi,
every time i export a database i loose the saved profiles. Is this the normal case?
-
This topic was modified 1 year ago by
alexf812.
-
This topic was modified 1 year ago by
-
Hi there,
WP Migrate Support Team here, Thanks for reaching out with your query we would be happy to assist!
Exporting a database should not cause your saved profiles to disappear. Could you please confirm if your saved profiles only disappear when you export a database? Have you also tried just refreshing the page and see if that also causes the saved profiles to disappear?
Can you also please check your browser’s debugging console to see if there are any errors reported when this occurs? For instructions on how to do this, see https://deliciousbrains.com/wp-migrate-db-pro/doc/debugging-browser-console-errors/.
Please also try editing your wp-config.php file on your server to replace this line –define( 'WP_DEBUG', false );
With these lines –define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This will cause all runtime errors, warnings, and notices to be written to/wp-content/debug.log, which will hopefully yield some better information about what’s going on.
Can you try the process again and then send on thedebug.logfile if created, please?
More details about that at https://wordpress.org/support/article/editing-wp-config-php/#wp_debug
Once we have finished troubleshooting, you should revert that config change and delete the debug.log file.
We look forward to hearing back.Hi,
i use this Plugin on many Pages with different configurations and different hosting. The profiles will never be saved, no matter what system.
I compared the database before and after export. Before there is an entry wpmdb_saved_profiles in the wp_options table with option_value containing all the data. After exporting the database, the entry does not exist and all other entries beginning with wpmdb are gone, except wpmdb_usage. After opening the WP-Backend the entries wpmdb_ are in the database again but they are empty
Hi @alexf812,
Thanks for letting us know. Would you be able to share any errors you may have seen? If you’ve enabled debugging, please share the contents of the /wp-content/debug.log file, if created.
Would you also be able to share the debugging information from the Help tab on the site you’re having trouble with?
- Go to the Help tab of your local install.
- Scroll down to the “Diagnostic Info & Error Log.”
- Copy the contents and paste it here. Feel free to remove any sensitive data.
We look forward to hearing from you!
Hi,
this is my Log from a local domain:
site_url(): http://xxxxxxxxxx.xx
home_url(): http://xxxxxxxxxx.xx
site_path(): xxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxx/xxxDatabase Name: xxxxxxxxxx
Table Prefix: xxxx_WordPress Version: 6.8
WP Migrate DB: 2.7.2
Web Server: ………………… Apache/2.4.63 (Unix) OpenSSL/3.3.3
PHP: ………………………. 8.4.5
WP Memory Limit: ……………. 40M
PHP Time Limit: …………….. 240
Blocked External HTTP Requests: None
fsockopen: …………………. Enabled
OpenSSL: …………………… OpenSSL 3.0.15 3 Sep 2024
cURL: ……………………… Enabled
Enable SSL verification setting: No
Opcache Enabled: ……………. DisabledMySQL: ………………. 10.11.6-MariaDB-1:10.11.6+maria~ubu2204
ext/mysqli: ………….. yes
WP Locale: …………… de_DE
DB Charset: ………….. utf8mb4
WPMDB_STRIP_INVALID_TEXT: NoDebug Mode: … No
Debug Log: …. No
Debug Display: Yes
Script Debug: No
PHP Error Log:WP Max Upload Size: 64 MB
PHP Post Max Size: 128 MBWPMDB Bottleneck: …… 1 MB
Compatibility Mode: …. Yes
Delay Between Requests: 0WP_HOME: ……. Not defined
WP_SITEURL: …. Not defined
WP_CONTENT_URL: http://xxxxxxxxxx.xx/wp-content
WP_CONTENT_DIR: xxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxx/xxx/wp-content
WP_PLUGIN_DIR: xxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxx/xxx/wp-content/plugins
WP_PLUGIN_URL: http://xxxxxxxxxx.xx/wp-content/pluginsMedia Uploads
Transfer Bottleneck: …… 64 MB
Upload Folder Permissions: 777Themes & Plugins
Transfer Bottleneck: ……… 64 MB
Themes Permissions: ………. 755
Plugins Permissions: ……… 755
Must-Use Plugins Permissions: 755
WP-Content Permissions: …… 755
WP-Core Permissions: ……… 755Active Theme Name: HoneyPress
Active Theme Folder: xxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxx/xxx/wp-content/themes/xxxxxxActive Plugins
- xxx
- WP Migrate Lite (v2.7.2) by WP Engine
Must-Use Plugins
- WP Migrate Lite Compatibility (v1.3) by Delicious Brains
This is from my debug.log:
[26-Apr-2025 14:51:29 UTC] PHP Deprecated: DeliciousBrains\WPMDB\Container\DI\Container::__construct(): Implicitly marking parameter $wrapperContainer as nullable is deprecated, the explicit nullable type must be used instead in /xxxxx/xxxx/wp-content/plugins/wp-migrate-db/vendor/php-di/php-di/src/DI/Container.php on line 70
[26-Apr-2025 14:51:29 UTC] PHP Deprecated: DeliciousBrains\WPMDB\Common\Queue\Connection::__construct(): Implicitly marking parameter $wpdb as nullable is deprecated, the explicit nullable type must be used instead in /xxxxx/xxxx/wp-content/plugins/wp-migrate-db/class/Common/Queue/Connection.php on line 18
[26-Apr-2025 14:51:29 UTC] PHP Deprecated: DeliciousBrains\WPMDB\Container\Invoker\Invoker::__construct(): Implicitly marking parameter $parameterResolver as nullable is deprecated, the explicit nullable type must be used instead in /xxxxx/xxxx/plugins/wp-migrate-db/vendor/php-di/invoker/src/Invoker.php on line 33
[26-Apr-2025 14:51:29 UTC] PHP Deprecated: DeliciousBrains\WPMDB\Container\Invoker\Invoker::__construct(): Implicitly marking parameter $container as nullable is deprecated, the explicit nullable type must be used instead in /xxxxx/xxxx/plugins/wp-migrate-db/vendor/php-di/invoker/src/Invoker.php on line 33
At the moment i made a database export on 3 Installations and no profiles are saved. After every export i have to create new profiles. That is always very time-consuming and not what i expect.
Is there an option? I am missing something? In total i have 8 installations and the same behavior everywhere.
-
This reply was modified 9 months, 4 weeks ago by
alexf812.
Hi @alexf812,
Thanks for sharing those. Just to clarify, it sounds like after running an export, the saved profiles disappear from the source site and not just from the exported file. This happens across all your installations. Is that correct?
Normally, saved profiles remain intact on the source site even after an export. However, they are not included in the exported database, which is expected. At the moment, exporting/importing saved profiles isn’t supported, but we do have an internal feature request for that.
The log messages you shared are PHP deprecation notices, and shouldn’t affect the saved profiles.
Could you please check if there are any errors in the browser’s console on the Profiles page, either before or after an export? It might help to temporarily disable other plugins and switch to a default theme to see if that makes a difference. We also recommend clearing any cache before trying another export.
Please let us know how that goes!
Hi,
At the moment, exporting/importing saved profiles isn’t supported
exactly this is the problem.
yes profils remain intact but only on the source. If i import in another environment the profile are gone I am the only one who uses profiles? What is an efficient way if i often have to copy databases from dev to live or back from live to dev? Every time i have to add the path and domain again.
Hi @alexf812,
Thanks for confirming! Yes, that’s expected behavior. Saved profiles remain on the source site but aren’t included in the export or import process, as profile migration isn’t currently supported.
We understand how helpful it would be to migrate profiles between environments. While we do have an internal feature request open for this, we can’t guarantee if or when it might be implemented.
We know it’s not ideal, but for now, you’ll need to manually recreate and save the same profile setup on the destination site.
Please let us know if you have more questions.
The topic ‘Export Profiles’ is closed to new replies.